Current network services, including Internet services, generally require that a user directly invoke the service. Once the service is invoked, the invoked service is responsible for fulfilling the request. For example, on the Internet, a person invokes a service by submitting a request via his or her PC. The invoked service fulfills the request.
As a specific example, a person may order the latest book “Tishimingo Blues” by Elmore Leonard using the well-known Amazon.com website. The user clicks on a series of icons in the Amazon website corresponding to the title and then checks out by entering various shipping and payment information, thus submitting the order. Once submitted to Amazon, the order is processed by Amazon and the book is shipped to the person.
In some cases, a network service node may create and maintain a database that automatically returns results to a person that access the node. For example, many websites create preferences based on a person's prior purchases or queries. Software “cookies” are stored on the person's PC, and automatically transmitted to the website when the person accesses the website. The cookies identify the terminal (and by surrogate, the person) to the service node, the preferences for the person are retrieved by the service node from the database, and purchasing suggestions are made to the person based on the preferences. The preferences tendered, however, are routinely developed and proffered by the website entity itself based on its own commercial goals. They are not, for example, formulated and proffered in response to the device used to invoke the website, or tailored to a service invoked by the user.
There are a number of disadvantages with this arrangement. One principle disadvantage is that the user invokes and thus selects the service node to service his or her request. However, this requires that the user know how to formulate a request, navigate the network and find a servicing node. The servicing node that the user finds, however, may not be the optimum provider. For example, a user living in Europe may invoke a website in Wyoming to service the request, thus incurring additional shipping costs and delays, when there is a local alternative that could have serviced the request faster and cheaper.
Another disadvantage of direct invocation of a network servicing node by users, and the servicing of those requests by the service node, is that the service node can be overwhelmed by user requests. This can lead to delays in servicing the request. This is particularly disadvantageous when another servicing node might be immediately available to provide an equivalent service to the excess users.
Another disadvantage of direct invocation of a network servicing node by users is that a person must recognize that he or she needs the service and actively access the servicing node by formulating and manually entering a request. If, for example, a user is about to put a silk shirt from the Gap into a washing machine at the wrong temperature, but does not realize it, it makes no difference that the Gap website may include washing instructions for its products. Even in the case of the servicing node that automatically provides preferences to the user who access the servicing website, the user must first access the website and, even then, the preferences that are returned by the website are developed by the website and may have nothing to do with the user's current needs.
A local network has certain analogous features and disadvantages. For example, a work facility may have card readers at each entrance that are connected to a facility server. When a worker swipes his or her ID at one of the readers (thus identifying himself or herself to the system), a database is consulted to determine that the person is currently employed. If so, the server returns a signal to open the door latch corresponding to the reader. Again, the person directly invokes the service by providing the ID to the card reader, and the invoked service provides the result (a door unlock command).
Continuing the local network example, more than one parameter apart from the person's ID may be submitted to the server in the service request. For example, the facility may have a number of secure rooms to which access is restricted to certain employees. When a person swipes an ID at a particular reader, the person's ID and the reader location (two parameters) is used to look up in the database whether the particular person is allowed access to the room corresponding to the reader. If so, the server sends an unlock command. If not, then the door remains locked.
Additional parameters may be considered with the service request. For example, the server may also consider other parameters in determining whether to allow the person access to the room. For example, if the database reflects that the person works normal business hours and he is swiping his ID at a reader for a secure room at 1 a.m., then the door may remain locked.
Even in a local network environment as described, the user must be aware of the service and actively invoke the service. The database relied on is dedicated to a particular function, such as unlocking an entrance and does not accommodate other devices. The network server may also be overwhelmed if multiple users invoke the service simultaneously. Even if there are multiple servers that can accommodate excess service requests, the routing of requests may not be invoked in the most efficient manner.